F18A

[+retroclouds]

Well, Pitfall is fixed!! It was the early clock, which of course ended up being a major change to other sprite related stuff. However, the problem wit Bigfoot still exists and it is exactly the same! I was hoping fixing one would correct the other, but apparently not. But Bigfoot will have to wait until tomorrow.

 

Matthew

 

Hi Matthew,

 

sorry for my late reply. So it seems you were able to resolve the Pitfall issues?

I should check the source code, but it could be that the title screen is in a "hybrid" VDP mode.

I captured the values for the VDP registers directly from the colecovison emulator (I think it was MEKA).

 

I remember that I had to fiddle with the scrolling Acttivision logo and color bar until I got it working on an unexpanded TI-99/4A.

There was something strange with the color bar, think I had to replace characters once the color bar

got in the middle part of the screen or something.

I was quite surprised it even did work, it was more of a trial & error thing really

 

Anyway, very impressive stuff you are doing there! :thumbsup:

[matthew180]

Hey Retroclouds, yeah, you did use a hybrid mode, and the early clock bit, so it was a really good way to test. I found the problem with the Bigfoot title screen too, and that is fixed now. When I saw the same vertical lines appear while I was testing a game of Parsec, it clicked in my head what must be going on.

 

So, sprite magnification is next. Let's see how long that one takes (and what new problems it introduces.)

 

Matthew

[matthew180]

Ok... Magnification is done. Now I just have to get that "partially signed" Y coordinate "thing" worked out and all the original functionality will be done! Just might have it done by Friday.

 

Matthew

[Opry99er]

Wow man. Congrats. This is great news for the 99er community.

[Tursi]

Very, very nice!

 

Is the sprite hardware collision bit in place? And it's set on the scanline that the collision occurs, right? I want to use that feature someday, and I know the Coleco and MSX folks use it. (Same deal with the 5-on-a-line bit, but less often used, and since you weren't going to enforce that, that one is less important).

[matthew180]

Hmm, actually I forgot about that collision bit. Should not be too difficult to get that added. It will be set on the scanline *after* where the sprites were in collision, just like sprites are drawn one scanline below their Y coordinate.

 

I'll probably still report the 5th sprite on a line too, just for compatibility.

 

Matthew

[matthew180]

Okay, I finally got the magnification and vertical coordinates working correctly. When I was working on the vertical coordinates I found a small bug in the magnification code, but it is all straight now. Here are a few interesting pictures during the process of adding sprite magnification.

 

In the case of the 16x16 sprite, the addressing for the second byte was still in non-magnification mode, so it was a hybrid sprite. Kind of cool, but not anything that was available on the real hardware, so you won't ever see that again.

 

The 8x8 sprite was addressing correctly, but the logic that checked the size of the sprite saw that it was over 8 pixels, so the second byte was pumped out, which produced a duplicate. So here we see a 16x32 pixel magnified sprite.

 

It is all fixed now and the vertical addressing is working as well. I did find a small bug in Classic99 as well, but I'll show it to Tursi at the Faire and we can hypothesize about what might be happening and how to fix it. I wonder how many people in the world think that sounds like fun?

 

Matthew

[Opry99er]

That hybrid SPRITE is awesome...

[sometimes99er]

nbsp;

Edited November 7, 2010 by sometimes99er

[Tursi]

Hmm, actually I forgot about that collision bit. Should not be too difficult to get that added. It will be set on the scanline *after* where the sprites were in collision, just like sprites are drawn one scanline below their Y coordinate.

 

I'll probably still report the 5th sprite on a line too, just for compatibility.

 

Matthew

 

That would be just fine! The real 9918 is a bit slow to actually update the register, so even one scanline late is tighter than the real thing.

 

The Classic99 bug will be interesting. I fixed a major CPU one this week but I think I caused some new ones, in addition I have new reproducable differences - TurboForth no longer works on Classic99 but works on my hardware, and the program I was working on for the faire worked fine on Classic99 but behaved oddly on real hardware. That and some debugger bugs, it's like C99 experienced some bitrot.

 

The CPU bug had to do with post increment... the Corcomp RAM tester was doing this:

 

MOV R0,*R0+

 

Classic99 was doing the post increment after looking up the address of both registers, but before doing the MOV, so the target address was getting the post incremented value of R0. I had to tweak the low level parsing code of the CPU to fix that one, but before I release it it needs more testing for the other weirdness now exposed.

 

Anyway, as for the VDP, very, very cool to see this coming along so well!

[matthew180]

That would be just fine! The real 9918 is a bit slow to actually update the register, so even one scanline late is tighter than the real thing.

 

The datasheet mentions 1/60th or 1/50th time frames... I think the assumption is that you will only check the collision bit what you read the status register after receiving the VDP interrupt. But I'm pretty sure internally the collision bit is getting set the moment any two sprite X coordinates overlap.

 

The CPU bug had to do with post increment... the Corcomp RAM tester was doing this:

 

MOV R0,*R0+

 

Classic99 was doing the post increment after looking up the address of both registers, but before doing the MOV, so the target address was getting the post incremented value of R0.

 

Wow. I would think a bug like that would have been exposed sooner. Or is it only happening when the src and dst registers are the same? I use post-increment all the time that way and the code works with Classic99, and I usually also test on real hardware.

 

Anyway, as for the VDP, very, very cool to see this coming along so well!

 

Yup, the VDP is pretty much done as far as original functionality is concerned. I really did not expect to have it to this point by the Faire. Heck, a week ago or so sprites did not even exist on the thing! If I limit the initial release to original functionality, I could probably have boards done by the end of Q1 2011 (now I sound like some big-name company talking about release dates! haha)

 

Matthew

Edited November 5, 2010 by matthew180

[Tursi]

The datasheet mentions 1/60th or 1/50th time frames... I think the assumption is that you will only check the collision bit what you read the status register after receiving the VDP interrupt. But I'm pretty sure internally the collision bit is getting set the moment any two sprite X coordinates overlap.

 

It 100% does - I posted a video showing this on hardware a couple of years ago, and there are some MSX demos that use it for timing (for instance, since the 9918 checks all of its registers every scanline, you can change the video mode mid-screen. Using a sprite collision helps you detect WHEN mid-screen occurs.)

 

The CPU bug had to do with post increment... the Corcomp RAM tester was doing this:

MOV R0,*R0+

 

Wow. I would think a bug like that would have been exposed sooner. Or is it only happening when the src and dst registers are the same? I use post-increment all the time that way and the code works with Classic99, and I usually also test on real hardware.

 

Only if the registers are the same, I think. I can't think of a case where you'd see it otherwise, since the fault is when in the opcode function the post-increment occurs.

[+InsaneMultitasker]

Seeing this at the Faire and watching the hardware do its thing* was quite amazing! I really enjoyed seeing the sprites on/off, blanking on/off, etc. And what was that about having a v9938/58 core complete by the time you return home?? <big grin>

 

Tim

 

 

 

*faire demos are notorious for not working at the most inopportune moment

Edited November 7, 2010 by InsaneMultitasker

[matthew180]

Thanks Tim. I had a great time watching you and Marc trying to get that Geneve code working too. Oh, I finished the whole 38/58/9999 cores last night after the pub crawl, and threw in the 9900 core too in my spare time. Boards will be ready tomorrow.

 

Matthew

[+acadiel]

Thanks Tim. I had a great time watching you and Marc trying to get that Geneve code working too. Oh, I finished the whole 38/58/9999 cores last night after the pub crawl, and threw in the 9900 core too in my spare time. Boards will be ready tomorrow.

 

Matthew

 

Can I have fries with that?

[+Vorticon]

Thanks Tim. I had a great time watching you and Marc trying to get that Geneve code working too. Oh, I finished the whole 38/58/9999 cores last night after the pub crawl, and threw in the 9900 core too in my spare time. Boards will be ready tomorrow.

 

Matthew

 

I hope you didn't have too much of a hangover after all the water you drank

[matthew180]

Hey, I was drinking diet coke! Only water when they tried to give me diet pepsi. It seems you can't get coke in Evanston.

[marc.hull]

All right here are my requests for the left over bits in byte 4 of the SAT just remember you asked.

 

1) Eliminate masking if >4th sprite on a line. This would give you the best of both worlds. Some would mask out others not.

2) Ability to take on a lower priority than the graphics so they could slide out of site under a tile.

3) ????

 

I'll keep thinking...You keep coding

[matthew180]

Actually, the 9938 blows those bits (it uses them in other ways.) So if I'm going to add any kind of 9938 compatibility, then I have to do it *their way*. As for more than 4 sprites on a single line, I was going to just add a new F18A specific register to control that kind of stuff. Seems like the safest way.

 

But keep thinking.

[Tursi]

Oi.. I can't believe I forgot that feature, but yes, some kind of priority register for sprites that at least lets you put some sprites UNDER the playfield would be absolutely fantastic!

 

As for other ideas, here's a link to the GBA spec I mentioned. I quite like the way they layout video memory - it's similar to the TI, but adds a lot of flexibility (more bits for the character number to allow larger character sets, as well as per-character palette and flip options): http://nocash.emubase.de/gbatek.htm#gbalcdvideocontroller

 

The reference format may take a few reads to make sense of, but I offer it only for ideas, by no means am I saying I really need any of these features.

[matthew180]

Quick update:

 

Well, I read the 9938 datasheet. Now I remember why I don't like the 9938. Ugh.

 

I fixed the sprite collision bit in the status register. It works better when you put the bit in the proper place. There was also another small bug with the detection, but it is working now and Neverlander is a bit harder now...

 

I started looking into the board design in earnest and my idea of a design quickly went from two ICs to six! Seems FPGA's have pretty complex power requirements (no less than 3 separate voltages) and it will take a dedicated power IC and related components to manage the beast. Then there is the external SRAM, PROM, DAC, and USB controller. That also makes for a larger board than I was hoping for.

 

Options are to toss out the DAC (sticking with 9-bit color instead of 24-bit color), the SRAM (no enhanced VRAM), and USB (no field updates, keyboard, or mouse) and go with the FPGA, PROM (required), and power management.

 

Of course everything affects the cost too, but the FPGA is by far the most expensive single part, with all the other ICs totaling about the same as the FPGA. Unless I make 50,000 of these, I can't see making the original $80 price point.

 

I'm also beginning to question whether I can actually design such a board and have it *work*...

 

Matthew

[djpubba]

I think the majority of interest is going to come from folks who just want true VGA out from their TI. Anything else is for the hardcore. So maybe two versions? One cheap for the majority of buyers so you'll sell a bunch and make money, and be able to afford to make an expensive version for the hardcore minority.

[Willsy]

Yeah, sprite priority registers! Now we're talking... You could do that with the commdore 64 - sprites could be in front of, or behind the bitmap, selectable on an individual sprite by sprite basis IIRC.

 

We'd need 4 extra registers, giving us 32 bits. Say, 0 (default)=normal behaviour (on top of background) and 1=behind

 

Question: If sprites 0 and 1 are active, and sprite 0 is set behind the background, and 1 on top, how does one handle the layering/ordering of sprites? I mean, sprite 0 has a higher priority than sprite 1. That's a tough one

[marc.hull]

Quick update:

 

Well, I read the 9938 datasheet. Now I remember why I don't like the 9938. Ugh.

 

I fixed the sprite collision bit in the status register. It works better when you put the bit in the proper place. There was also another small bug with the detection, but it is working now and Neverlander is a bit harder now...

 

I started looking into the board design in earnest and my idea of a design quickly went from two ICs to six! Seems FPGA's have pretty complex power requirements (no less than 3 separate voltages) and it will take a dedicated power IC and related components to manage the beast. Then there is the external SRAM, PROM, DAC, and USB controller. That also makes for a larger board than I was hoping for.

 

Options are to toss out the DAC (sticking with 9-bit color instead of 24-bit color), the SRAM (no enhanced VRAM), and USB (no field updates, keyboard, or mouse) and go with the FPGA, PROM (required), and power management.

 

Of course everything affects the cost too, but the FPGA is by far the most expensive single part, with all the other ICs totaling about the same as the FPGA. Unless I make 50,000 of these, I can't see making the original $80 price point.

 

I'm also beginning to question whether I can actually design such a board and have it *work*...

 

Matthew

 

 

 

Of course it will work Matt. Just keep banging that head of your on the wall until it does ....

 

I agree with the other posters that the VGA output is what is going to make this a sellable and great project. If the other stuff gets shelved then so be it. Remember to keep it simple bro..... and please hurry every chance you get hehehe.....

[Willsy]

I agree with the other posters that the VGA output is what is going to make this a sellable and great project. If the other stuff gets shelved then so be it. Remember to keep it simple bro..... and please hurry every chance you get hehehe.....

 

Agree. VGA is what it's all about. I want a nice LCD monitor for my TI.

 

If we can get 9938 emulation, then WOW! 80 columns straight out of the console - awesome.