F18A

[Tursi]

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.

 

I guess $20 doesn't include assembly? If it does I think I'd like to use them for some protos too. I agree I wouldn't use SunStone for raw PCBs.

 

We used them because they do everything. I am not fully aware of the process used to select them, except that they turned out better than several others that were investigated. The did the prototype, but because of the cost I went with a company in Malaysia for the first run of 50 Skunkboards, and was very unhappy with the result (better than 40% failed - mostly due to visible build errors). SC did substantially better on the second run of 100 Skunkboards, although I don't remember the exact failure count offhand. We have thus gone straight to them for the third run, and except for a few snags communicating intent, they were very good and quite helpful.

[matthew180]

Thanks for that info.

 

No, the $20 I mentioned did not include any assembly, just boards. BatchPCB charges a flat rate and they calculate the cost based on board square inches.

 

There are a lot of board houses now, and having a lot of choices is a good thing, but picking one is pain in the ass.

[bmcnett]

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?

 

Ah, I hadn't considered that people were using BASIC still. That case is SO cpu-bound that the four-sprite limitation is clearly superior to bit-twiddling the sprite patterns. Sorry if I'm raising a fuss - I guess I come from a different culture. I'm a ColecoVision and ADAM user, and on those platforms a no-flicker default setting is an obvious win for everyone. ColecoVision is an interesting case for homebrew because, while as a game console it was mainstream in North America, due to licensing issues and its short life there are huge gaps in its catalog that are easy to fill by amateurs (e.g. Space Invaders) and its chipset is very conventional.

 

I thought of a flicker compromise that might or might not be useful: If on a scanline there is any sprite with all zeroes in its entire 16x16 bit pattern, then the four-sprite limitation applies to that scanline. If no such sprite is on that scanline, then the limitation is lifted.

[bmcnett]

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.

 

Yeah, that sounds exactly like my 16-bit HSV. It ended up having 32 hues and 8 saturations or 16 hues and 16 saturations, neither of which was enough to encode the 9918A's default palette IMO. I also don't have the bandwidth for full HSV, so I have both HSV and RGB palette registers, and do HSV->RGB only just after the CPU updates an HSV palette register.

 

Multicolor mode is actually pretty cool IMO because there are so few bytes to update that an old CPU can handle it. I may keep it as a 64x48, 256 color mode which could be "faster" than the original mode, because then at least the CPU wouldn't have to deal with masking and shifting nybbles all the time.

Edited February 23, 2011 by bmcnett

[matthew180]

Untangled wires.

 

To give you a sense of scale, the board is 54mm x 40mm (2.12" x 1.57"). That's smaller than a business card which is 2" x 3.5".

[Opry99er]

Man, that looks so cool.....

[Tursi]

Ah, I hadn't considered that people were using BASIC still.

 

You need to check out the other threads in this base, then.

 

I thought of a flicker compromise that might or might not be useful: If on a scanline there is any sprite with all zeroes in its entire 16x16 bit pattern, then the four-sprite limitation applies to that scanline. If no such sprite is on that scanline, then the limitation is lifted.

 

That's an interesting one.. expensive to do in hardware though (you need to fetch the whole pattern, and compare every byte). Also, the technique works with invisible sprites (color 0) -- although that would be easier to test for, hehe. Finally, not all titles used non-visible sprites to induce flicker. For my own part, I actually defined the lower indexed sprites as part of the scenery, so they were visible (rather than wasting four sprites! )

 

The lack of ability to switch the options in real time makes me a little sad... it's useful for debugging, investigation, and just plain messing around, that was why I loved the switches on the proto board. But the real chip doesn't have such switches so I think we'll be okay somehow..

[Tursi]

Untangled wires.

 

To give you a sense of scale, the board is 54mm x 40mm (2.12" x 1.57"). That's smaller than a business card which is 2" x 3.5".

 

A thing of beauty!!

 

Yeah, I was getting the scale from looking at the pins you spaced out for the 9918 socket. That's pretty awesome.

[bmcnett]

That's an interesting one.. expensive to do in hardware though (you need to fetch the whole pattern, and compare every byte). Also, the technique works with invisible sprites (color 0) -- although that would be easier to test for, hehe. Finally, not all titles used non-visible sprites to induce flicker. For my own part, I actually defined the lower indexed sprites as part of the scenery, so they were visible (rather than wasting four sprites! )

 

This raises an interesting issue - if I'm not mistaken the 9918A and its contemporaries did all sprite work afresh with each scanline. They did not, if I understand correctly, use the VBLANK to do things like scanline-sort or otherwise process the sprite table in anticipation of scanlines to come. This made possible scanline tricks on many platforms, but also as you say would have made it expensive in hardware to do things like examine sprite patterns.

 

I've seen MSX demos that have what look like scanline tricks, but I've never seen one on ColecoVision or ADAM, and don't know about TI-99/4A. My software VDP forbids such tricks, which enables a bunch of per-frame work to get done efficiently during VBLANK and during the frame itself. For example, batches of four scanlines are sometimes rendered in parallel ahead of the beam, which makes it possible to load fewer bits per pixel.

Edited February 23, 2011 by bmcnett

[matthew180]

The lack of ability to switch the options in real time makes me a little sad... it's useful for debugging, investigation, and just plain messing around, that was why I loved the switches on the proto board. But the real chip doesn't have such switches so I think we'll be okay somehow..

 

You will have the options, just not via a physical switch. I think to total number of people who would want such a thing is 1. You. We'll see what happens in future versions.

[Tursi]

The lack of ability to switch the options in real time makes me a little sad... it's useful for debugging, investigation, and just plain messing around, that was why I loved the switches on the proto board. But the real chip doesn't have such switches so I think we'll be okay somehow..

 

You will have the options, just not via a physical switch. I think to total number of people who would want such a thing is 1. You. We'll see what happens in future versions.

 

Yeah, but they are useless to me for those purposes if they are software switches, too. I can't load a third party piece of software and write to the VDP while it's executing. (It's a different case if you are saying I just need to solder some very fine wires, I can do that. )

 

Otherwise, don't kill yourself making them work, especially for JUST me. I can come up with a way to toggle between 9918 and F18 if I /really/ need it, but more likely I'd do that sort of investigation with emulation.

[Tursi]

This raises an interesting issue - if I'm not mistaken the 9918A and its contemporaries did all sprite work afresh with each scanline. They did not, if I understand correctly, use the VBLANK to do things like scanline-sort or otherwise process the sprite table in anticipation of scanlines to come.

 

This is correct -- according to the chip designer it checks the SAL each scanline and determines which sprites need to be drawn, storing the first four in special registers. This is where the 4-on-a-line limit comes from. Then during the scanline it only needs to worry about those four sprites.

 

I've seen MSX demos that have what look like scanline tricks, but I've never seen one on ColecoVision or ADAM, and don't know about TI-99/4A. My software VDP forbids such tricks, which enables a bunch of per-frame work to get done efficiently during VBLANK and during the frame itself. For example, batches of four scanlines are sometimes rendered in parallel ahead of the beam, which makes it possible to load fewer bits per pixel.

 

Very, very, very few tricks made it onto the TI-99/4A, probably because comparably fewer people worked on it. That scan, the VDP checks everything per-scanline, so with very careful timing (usually cycle counting, since the VDP doesn't give external indications of scanlines), you can change any of the VDP registers between scanlines - so you can change colors, table addresses, or even video modes mid-screen.

 

There is one way to do it without continuous cycle counting -- using the sprite collision or 5-on-a-line bits in the VDP status register. If you set up your sprites so that it happens at a known point, and poll the register, you can tell within a couple of scanlines when the VDP is at a particular vertical point. I demonstrated this working on a 4A briefly, and I understand the MSX guys have used it. My vid was here: http://www.youtube.com/maliciousdolphin#p/u/7/3ioC3dqGxk8

[+5-11under]

The lack of ability to switch the options in real time makes me a little sad... it's useful for debugging, investigation, and just plain messing around, that was why I loved the switches on the proto board. But the real chip doesn't have such switches so I think we'll be okay somehow..

 

You will have the options, just not via a physical switch. I think to total number of people who would want such a thing is 1. You. We'll see what happens in future versions.

Make that 2! For me, this is an option I'd love to have available. For fancier graphics options, software/registers is the way to go, but for legacy software, such as any ColecoVision game that flickers, it'd be great to be able to switch between 4 and 32 sprites per scanline. I can't/won't be reprogramming any of the old (or newer) games that use flicker.

 

Don't worry, though. I'll still buy one from you.

[bmcnett]

Make that 2! For me, this is an option I'd love to have available. For fancier graphics options, software/registers is the way to go, but for legacy software, such as any ColecoVision game that flickers, it'd be great to be able to switch between 4 and 32 sprites per scanline. I can't/won't be reprogramming any of the old (or newer) games that use flicker.

 

What do most of the flickery ColecoVision games do at boot time? Call the BIOS routine that uploads the system logo and copyright screen to the 9918A. That could be the software switch that enables 32-sprite mode

[+5-11under]

Make that 2! For me, this is an option I'd love to have available. For fancier graphics options, software/registers is the way to go, but for legacy software, such as any ColecoVision game that flickers, it'd be great to be able to switch between 4 and 32 sprites per scanline. I can't/won't be reprogramming any of the old (or newer) games that use flicker.

 

What do most of the flickery ColecoVision games do at boot time? Call the BIOS routine that uploads the system logo and copyright screen to the 9918A. That could be the software switch that enables 32-sprite mode

Interesting. Switching between 2 BIOSes in this way could work for at least some of the games... maybe there's a similar way to do this, regardless of whether the system logo is shown or not. I'm not too familiar with the BIOS, but it's probably possible... reset points to the BIOS, from what I understand.

[matthew180]

Yeah, but they are useless to me for those purposes if they are software switches, too. I can't load a third party piece of software and write to the VDP while it's executing. (It's a different case if you are saying I just need to solder some very fine wires, I can do that. )

 

Otherwise, don't kill yourself making them work, especially for JUST me. I can come up with a way to toggle between 9918 and F18 if I /really/ need it, but more likely I'd do that sort of investigation with emulation.

 

Well, there are extra I/O pins and I could expose the pads if anyone wanted to modify their board to accept inputs from switches... Now would be the time to add this "feature". So, what over rides are you looking for? I think these two are obvious:

 

1. 4 / 32 sprites on a line

2. Disable / enable sprites

 

What else? On my prototype board I had switches for testing that would show/hide the color bar, set a black/color border, enable/disable sprite, and original/alternate color palette. I don't think any of those would be useful. But, let me know what you would want and I'll see what I can do about getting some connection points.

[matthew180]

This is correct -- according to the chip designer it checks the SAL each scanline and determines which sprites need to be drawn, storing the first four in special registers. This is where the 4-on-a-line limit comes from. Then during the scanline it only needs to worry about those four sprites.

 

Another fact is, the sprites are drawn on the *next* scanline, which means if a sprite has a Y coordinate of 0, it will really appear on line 1. You can see this affect in XB. Another interesting fact is, MSX BASIC knows this and compensates for it!!

 

Classic99 knows about this trait, as does the F18A.

[Tursi]

Well, there are extra I/O pins and I could expose the pads if anyone wanted to modify their board to accept inputs from switches... Now would be the time to add this "feature". So, what over rides are you looking for? I think these two are obvious:

 

1. 4 / 32 sprites on a line

2. Disable / enable sprites

 

What else? On my prototype board I had switches for testing that would show/hide the color bar, set a black/color border, enable/disable sprite, and original/alternate color palette. I don't think any of those would be useful. But, let me know what you would want and I'll see what I can do about getting some connection points.

 

Appreciate the effort but I really don't want you to do extra work on my behalf!! With that in mind, the two you listed are good, but I thought you also had one to disable blanking (nice to have to see what's going on under the blank screen, hehe).

 

So that'd be:

 

1. 4 / 32 sprites on a line (board default whichever you decide - I think it should be 4, but can live fine with 32 since it can be made switchable)

2. Disable / enable sprites (board default enabled, of course)

3. Disable / enable blanking (board default enabled, of course)

 

The other one that Classic99 supports that I teasingly suggested to you at the faire was the ability to display the character set. All this does is replace the SIT lookup with a counter running from 0-255. Certainly not important though.

 

Of the switch options above, I do feel strongly about the sprite one - it should be a hardware select rather than a software one IMO, if only to reduce the amount of software written especially for it. 2 and 3 are just "nice to have", while 4 which I didn't even number is more along the lines of "silly".

 

Maybe now is the time to start creating test software for some of the more unusual features of the VDP? Do you have test software for the various Bitmap masking modes and the sprite ghosting? (The only two oddball effects I know about, anyway).

[+5-11under]

The original/alternate color palette sounds interesting... being able to switch between natural and a somewhat more saturated set of colors could be useful.

[matthew180]

Appreciate the effort but I really don't want you to do extra work on my behalf!! With that in mind, the two you listed are good, but I thought you also had one to disable blanking (nice to have to see what's going on under the blank screen, hehe).

 

Actually, after you mentioned it, I figured it would be nice to have some switches for myself too. See, I stopped using my devboard for now once I realized I read the datasheet wrong and discovered the I/O's on the FPGA are *not* 5V TTL tolerant! Hence the level shifter on the board (which I am not happy about, that thing takes up a lot of room and made the design a lot harder. So, I need one of these too, to keep working on the VHDL part (or get a level shifter for my devboard, which I will probably do soon too.)

 

Oh yeah, I forgot about the blanking. Actually, that was initially a mistake on my part, but I found it useful once I discovered the bug and made it switch selectable on the devboard.

 

Maybe now is the time to start creating test software for some of the more unusual features of the VDP? Do you have test software for the various Bitmap masking modes and the sprite ghosting? (The only two oddball effects I know about, anyway).

 

I don't currently have any *real* testing software. Not any that tests specific functionality anyway. I have games like Popeye and Bigfoot though, and some others that I know use the 4-sprite limit like Marc's Neverlander. At the Faire I discovered I had a game or two for the MSX on a developer cartridge that I bought recently (and never messed with yet.) So that is good too.

 

But, if you want to write something that tests certain characteristics, that would be fantastic! I do have the VDP overrun code that Marc posted a while ago. I still have to test that, and it will be very interesting to see the results.

[matthew180]

The original/alternate color palette sounds interesting... being able to switch between natural and a somewhat more saturated set of colors could be useful.

 

It is nice to have the alternate colors. Originally, before I tried to match the original colors, I just set the basic colors to their full-on RGB values, like 7-0-0 for red, 0-7-0 for green, etc. (remember I only have 3-bits per pixel, so each color goes from 0 to 7 instead of 0 to 255 that you have with 24-bit color.) Once I implemented the original palette, I found that I liked the pure colors better, so I set up both palettes and made them switch selectable for testing.

[matthew180]

Ok, I spent the day adding a 4 block jumper header for those who will want to set certain configuration parameters manually, or by adding switches. Currently the four that seem to be the most requested are:

 

1. Sprite limit on / off

2. Original palette / alternate palette

3. Sprites on / off

4. Blanking honor / ignore (not vertical blanking, but the VDP Register 1, bit 1 "blank enable / disable")

 

Here are some updated board images. I think I'm about ready to order a few prototypes!

[Tursi]

Getting pretty exciting!!

 

I'll see if I can put together a single test program that will exercise the bitmap masking and sprite artifacting - what are you using to load test software, so I write it for the correct target?

[matthew180]

A >6000 cart image is best so I can make a real cartridge to test with. Actually, now that I have the CF7, I guess any program that will run from that too. Thanks!

[Opry99er]

looking forward to the tests!! =)